Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

 

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

Is it really necessary for your system to accelerate so slowly?    Systems with motors that take more than 2 seconds to ramp up to speed are uncommon.  I doubt if there is any real benefit in setting the acceleration that low.

FYI the Jogging is performed using 3rd order motion using the Acceleration and Jerk Settings in KFLOP (not the Trajectory Planner Screen).  The Speed is set in the Trajectory Planner Screen.   There are two Jog buttons a "fast" and a "slow".  The specified speed sets the speed for the "fast" button and the %slow setting sets the percentage for the slow button.

Regards
TK

On 10/30/2016 4:10 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

Hi Greg,

Well to move slow doesn't necessarily need to accelerate so slowly.  Its one thing to move at a snail's pace but why require 13 seconds to accelerate to the snail's pace?  That's very slow acceleration.  I could see that if a motor has to spin up to 3000 RPM to achieve that speed it might take a second or so but probably not 13 seconds.

I don't know why you get that GCode error for Simulation.  Did you try our pre-compiled KMotionCNC?  Does it work there?

Regards

TK

 

Hi Tom,

Acceleration:
- This may be a result of my inexperience tuning the motors.  I found it was much easier to lower the acceleration and have the position follow the commanded.  Now that I understand it a bit better I'll go back and see what I can tweak out of it.
- The VFD's are programmed to accelerate the motors to full speed in 0.1 second.  When operated independent of the kflop they have never faulted, so I'm going to assume that the motors themselves are capable of higher acceleration, whether or not kflop can detect that acceleration (due to backlash) is another question. 

To answer your question, is it necessary to accelerate so slowly?  No, but it also doesn't need to accelerate faster either.  Cutting stone is very slow operation, with rates measured in inch/hour.

I'll go back to tuning... I thought I was so close to coordinated motion!
Greg.

On 10/30/2016 8:38 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

Is it really necessary for your system to accelerate so slowly?    Systems with motors that take more than 2 seconds to ramp up to speed are uncommon.  I doubt if there is any real benefit in setting the acceleration that low.

FYI the Jogging is performed using 3rd order motion using the Acceleration and Jerk Settings in KFLOP (not the Trajectory Planner Screen).  The Speed is set in the Trajectory Planner Screen.   There are two Jog buttons a "fast" and a "slow".  The specified speed sets the speed for the "fast" button and the %slow setting sets the percentage for the slow button.

Regards
TK

On 10/30/2016 4:10 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

 

Hi Greg,

Well to move slow doesn't necessarily need to accelerate so slowly.  Its one thing to move at a snail's pace but why require 13 seconds to accelerate to the snail's pace?  That's very slow acceleration.  I could see that if a motor has to spin up to 3000 RPM to achieve that speed it might take a second or so but probably not 13 seconds.

I don't know why you get that GCode error for Simulation.  Did you try our pre-compiled KMotionCNC?  Does it work there?

Regards

TK

On 10/30/2016 8:17 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi Tom,

Acceleration:
- This may be a result of my inexperience tuning the motors.  I found it was much easier to lower the acceleration and have the position follow the commanded.  Now that I understand it a bit better I'll go back and see what I can tweak out of it.
- The VFD's are programmed to accelerate the motors to full speed in 0.1 second.  When operated independent of the kflop they have never faulted, so I'm going to assume that the motors themselves are capable of higher acceleration, whether or not kflop can detect that acceleration (due to backlash) is another question. 

To answer your question, is it necessary to accelerate so slowly?  No, but it also doesn't need to accelerate faster either.  Cutting stone is very slow operation, with rates measured in inch/hour.

I'll go back to tuning... I thought I was so close to coordinated motion!
Greg.

On 10/30/2016 8:38 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

Is it really necessary for your system to accelerate so slowly?    Systems with motors that take more than 2 seconds to ramp up to speed are uncommon.  I doubt if there is any real benefit in setting the acceleration that low.

FYI the Jogging is performed using 3rd order motion using the Acceleration and Jerk Settings in KFLOP (not the Trajectory Planner Screen).  The Speed is set in the Trajectory Planner Screen.   There are two Jog buttons a "fast" and a "slow".  The specified speed sets the speed for the "fast" button and the %slow setting sets the percentage for the slow button.

Regards
TK

On 10/30/2016 4:10 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

Hi,
After a long night of going around in circles I think I have found a setting in the VFD that may help. 

I think this is a case of dueling PID loops.  One in Kflop, one in the VFD.  The trick will be getting them to coordinated.  VFD's can operate in "Vector control", either speed or torque based.  I have mine setup in speed.  When in vector mode the drive has a "Speed Controller".  To get a base line for the PID values you run an auto tune with the load connected and at 20-40% speed.  This comes up with some base line values.  That's what I have been using up to now.  The aha moment came when I read this about the controller:
2304 ACC COMPENSATION - Defines the derivation time for acceleration/(deceleration) compensation. In order to compensate inertia during acceleration, a derivative of the reference is added to the output of the speed controller.

I figured if I boosted that value I could get the acceleration up.  The auto tune value was 0.15s, I pumped it up to 20 and got promising results. I can get better acceleration matching with higher values, but then the at rest oscillations become pretty bad.

There are two plots attached.  One with Acc comp set to 20 and one with it at 110.  The one at 110 eliminates that 1sec delay at the beginning of a move but isn't stable at rest, the one with 20 is getting close but still oscillates quite a bit at rest.

I also tried running the VFD in scalar mode, which has no Speed Controller, this didn't yield very good results.

Any thoughts?
Thanks.


Settings for this plot: v30a30j100p170i0.01MaxI2000MaxErr200MaxOutput2047_VFDPID_p5.17i1.03d0acc110


Settings for this plot: v30a30j100p170i0.01MaxI2000MaxErr200MaxOutput2047_VFDPID_p5.17i1.03d0acc20







On 10/31/2016 8:28 AM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi Tom,

Hopefully I'll get time today to try with higher acceleration.
I am using the precompiled KMotionCNC.  I'll have to see what I changed in the setup that is a causing it, because before I setup KMotionCNC for my saw I was able to simulate GCode. 

Greg
On 10/31/2016 1:11 AM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Well to move slow doesn't necessarily need to accelerate so slowly.  Its one thing to move at a snail's pace but why require 13 seconds to accelerate to the snail's pace?  That's very slow acceleration.  I could see that if a motor has to spin up to 3000 RPM to achieve that speed it might take a second or so but probably not 13 seconds.

I don't know why you get that GCode error for Simulation.  Did you try our pre-compiled KMotionCNC?  Does it work there?

Regards

TK

On 10/30/2016 8:17 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi Tom,

Acceleration:
- This may be a result of my inexperience tuning the motors.  I found it was much easier to lower the acceleration and have the position follow the commanded.  Now that I understand it a bit better I'll go back and see what I can tweak out of it.
- The VFD's are programmed to accelerate the motors to full speed in 0.1 second.  When operated independent of the kflop they have never faulted, so I'm going to assume that the motors themselves are capable of higher acceleration, whether or not kflop can detect that acceleration (due to backlash) is another question. 

To answer your question, is it necessary to accelerate so slowly?  No, but it also doesn't need to accelerate faster either.  Cutting stone is very slow operation, with rates measured in inch/hour.

I'll go back to tuning... I thought I was so close to coordinated motion!
Greg.

On 10/30/2016 8:38 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

Is it really necessary for your system to accelerate so slowly?    Systems with motors that take more than 2 seconds to ramp up to speed are uncommon.  I doubt if there is any real benefit in setting the acceleration that low.

FYI the Jogging is performed using 3rd order motion using the Acceleration and Jerk Settings in KFLOP (not the Trajectory Planner Screen).  The Speed is set in the Trajectory Planner Screen.   There are two Jog buttons a "fast" and a "slow".  The specified speed sets the speed for the "fast" button and the %slow setting sets the percentage for the slow button.

Regards
TK

On 10/30/2016 4:10 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

 

Hi,
After a long night of going around in circles I think I have found a setting in the VFD that may help. 

I think this is a case of dueling PID loops.  One in Kflop, one in the VFD.  The trick will be getting them to coordinated.  VFD's can operate in "Vector control", either speed or torque based.  I have mine setup in speed.  When in vector mode the drive has a "Speed Controller".  To get a base line for the PID values you run an auto tune with the load connected and at 20-40% speed.  This comes up with some base line values.  That's what I have been using up to now.  The aha moment came when I read this about the controller:
2304 ACC COMPENSATION - Defines the derivation time for acceleration/(deceleration) compensation. In order to compensate inertia during acceleration, a derivative of the reference is added to the output of the speed controller.

I figured if I boosted that value I could get the acceleration up.  The auto tune value was 0.15s, I pumped it up to 20 and got promising results. I can get better acceleration matching with higher values, but then the at rest oscillations become pretty bad.

There are two plots attached.  One with Acc comp set to 20 and one with it at 110.  The one at 110 eliminates that 1sec delay at the beginning of a move but isn't stable at rest, the one with 20 is getting close but still oscillates quite a bit at rest.

I also tried running the VFD in scalar mode, which has no Speed Controller, this didn't yield very good results.

Any thoughts?
Thanks.


Settings for this plot: v30a30j100p170i0.01MaxI2000MaxErr200MaxOutput2047_VFDPID_p5.17i1.03d0acc110


Settings for this plot: v30a30j100p170i0.01MaxI2000MaxErr200MaxOutput2047_VFDPID_p5.17i1.03d0acc20







On 10/31/2016 8:28 AM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi Tom,

Hopefully I'll get time today to try with higher acceleration.
I am using the precompiled KMotionCNC.  I'll have to see what I changed in the setup that is a causing it, because before I setup KMotionCNC for my saw I was able to simulate GCode. 

Greg
On 10/31/2016 1:11 AM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Well to move slow doesn't necessarily need to accelerate so slowly.  Its one thing to move at a snail's pace but why require 13 seconds to accelerate to the snail's pace?  That's very slow acceleration.  I could see that if a motor has to spin up to 3000 RPM to achieve that speed it might take a second or so but probably not 13 seconds.

I don't know why you get that GCode error for Simulation.  Did you try our pre-compiled KMotionCNC?  Does it work there?

Regards

TK

On 10/30/2016 8:17 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi Tom,

Acceleration:
- This may be a result of my inexperience tuning the motors.  I found it was much easier to lower the acceleration and have the position follow the commanded.  Now that I understand it a bit better I'll go back and see what I can tweak out of it.
- The VFD's are programmed to accelerate the motors to full speed in 0.1 second.  When operated independent of the kflop they have never faulted, so I'm going to assume that the motors themselves are capable of higher acceleration, whether or not kflop can detect that acceleration (due to backlash) is another question. 

To answer your question, is it necessary to accelerate so slowly?  No, but it also doesn't need to accelerate faster either.  Cutting stone is very slow operation, with rates measured in inch/hour.

I'll go back to tuning... I thought I was so close to coordinated motion!
Greg.

On 10/30/2016 8:38 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

Hmmm.  The Jog buttons aren't set up for a machine that accelerates that slow.  To Jog it actually commands to move to a target position 2 seconds away.   It normally repeats that approximately every ~100ms.  The idea is that if Windows freezes or USB Communication dies the system will automatically stop after 2 seconds.  However for your system to make a move that ramps up to speed and back down to a stop will take:

40/3 x 2 = 27 seconds!

So there ends up being a conflict between needing 27 seconds of motion minimum to get up to speed and needing to stop in 2 seconds.

The line of Code in KMotionCNCDlg.c that imposes the 2 second limit is:

            s.Format("MoveRelAtVel%d=%f %f",CS_axis[i],v*2.0,fabs(v));

Is it really necessary for your system to accelerate so slowly?    Systems with motors that take more than 2 seconds to ramp up to speed are uncommon.  I doubt if there is any real benefit in setting the acceleration that low.

FYI the Jogging is performed using 3rd order motion using the Acceleration and Jerk Settings in KFLOP (not the Trajectory Planner Screen).  The Speed is set in the Trajectory Planner Screen.   There are two Jog buttons a "fast" and a "slow".  The specified speed sets the speed for the "fast" button and the %slow setting sets the percentage for the slow button.

Regards
TK

On 10/30/2016 4:10 PM, Greg Carter greg@... [DynoMotion] wrote:

 

Hi,

OK I'm running into a problem with my setup in KMotionCNC, the jog buttons cause odd movement.  If I hold either inner or the outer button for any direction the axis just cycles back and forth constantly switching directions and never really moving. I'm sure it's something I haven't configured correctly.

Axis Parameters:

My encoders are linear, with a resolution of 46.12 counts/mm so this gives me 1171.448 counts/inch.

Velocity. I'm setting this to the same max velocity I used in the Kmotion setup but converted to in/sec:

40 counts/sec, 46.12 counts/mm ~ 0.87mm/sec, 0.034 in/sec

Acceleration, again setting this to what I set up in Kmotion:

3 counts/sec^2, converted to inch is 3/46.12 = 0.065mm/sec^2 = 0.0026 inch/sec^2

Trajectory Planner I've left with the default values.

Jog I've set to the max velocity 0.034 inch/sec.  For the "Slow%" I tried default (25) and 1 and 100 didn't seem to make a difference.  This value isn't in the help file.

M0-M30 setup screen I've set everything but Halt and Prog Exit to None.

M100-M119 all None

User buttons first one set to my init thread.  Rest are not used.

Tool/Setup Files.  Left default.  Main Dialog Face: Basic 2 Axes.

Main and Trajectory Planner screens below.  I also am unable to simulate simple g code (box), I get a dialog with message of G Code error.  Made sure no other program is using kflop (Kmotion is NOT running).

Thanks again for any insight.

Greg.

Hi Tom,

You were correct, I was trying to use that setting for something it wasn't intended for.   For feedback the VFD's operate in "sensorless vector" mode.  The name is misleading.  It suggests no feedback, but what is meant is that there is no external sensor used for feedback.  Instead the VFD measures current and uses that in the feedback loop, this post describes it better http://www.practicalmachinist.com/vb/transformers-phase-converters-and-vfd/what-really-vector-sensorless-drive-276144/#post2170818

I went back to square one.  Reset the PID parameters in the VFD.  Ultimately ended up using the "auto tune" values the VFD came up with. 

Here is a plot of velocity using DAC commands.  Full speed is commanded for 5 seconds, then full reverse with no zero or delay, bit is toggled so you can see on the plot when the DAC command was sent.  This C code in a loop:
     DAC(CHANNELTOTEST, FULLSPEED_CW);
    SetStateBit(EVENTBIT, !ReadBit(EVENTBIT));
    Delay_sec(5);
  
    DAC(CHANNELTOTEST, FULLSPEED_CCW);
    SetStateBit(EVENTBIT, !ReadBit(EVENTBIT));
    Delay_sec(5);


 
And then I did a ramping test:
 
From these it seems that switching directions results in the delay and as you suspected is probably caused by backlash.  So I'm going to accept that for now.

This is where I settled:
    //xaxis   
    ch0->InputMode=ENCODER_MODE;
    ch0->OutputMode=DAC_SERVO_MODE;
    ch0->Vel = 45;
    ch0->Accel = 30;
    ch0->Jerk = 500;
   
    //test 2nd order speeds/accel/inf jerk
    //ch0->Vel=16.3;//max cutting speed
    //ch0->Vel=3.5;//min cutting speed
    //ch0->Vel=8;
    //ch0->Accel=3;
    //ch0->Jerk=500000000;
       
    ch0->P=140;
    ch0->I=0.0015;
    ch0->D=0;
   
    //yaxis
    ch1->InputMode=ENCODER_MODE;
    ch1->OutputMode=DAC_SERVO_MODE;
    ch1->Vel=100;
    ch1->Accel=150;
    ch1->Jerk=1000;
    //ch1->Jerk=10000000000;
    ch1->P=120;
    ch1->I=0.0015;
    ch1->D=0;

Unfortunately I'm running out of time as winter is supposed to hit here tomorrow and the saw will be under snow.  Today I was able to do a small test of some coordinated motion. I rigged up a pen to trace the movement, but the mount sucked and wasn't very ridged and it was pressing too hard on the paper.  So the drawn image is awful but I did log the error and it looks good.  For the most part error is less than 5 counts.  This is the error while drawing part of the circle (2" diameter):



Here's the image, it looks bad but I had to adjust the pen while it was moving and the mount wasn't ridged and it was humid out and the paper started to buckle...







Anyway this gives me hope. 

Also really like the screen editor. 



Thanks for your help getting it this far.
Greg.

 
On 11/1/2016 12:49 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

#1 I'm guessing that VFD Acceleration setting is Acceleration Feed Forward.  They take the derivative of the input, scale it by the setting, and add that to the output (Torque?).  I'm not sure it is very helpful.   I don't think your "problem" is with inertia.  Probably more to do with backlash, zero crossing distortion, and stiction.  Setting high Acceleration FF will give the system a big kick when the input changes which I thing is why you see some quicker response but probably isn't the right thing to do.  Something very similar could probably be obtained with higher gains. 

It isn't clear to me what the VFD uses for velocity feedback.  Do you know? Is there an encoder on it?

It might be worth while to characterize your VFD by simply commanding constant (or maybe ramping) velocity (DAC) commands.   Of course ideally the VFD should instantly go to and hold the commanded speed.   So this approach allows you to observe/test the VFD + Mechanism characteristics by themselves.  Crossing through zero speed would be of great interest.  Then adjust the VFD setting to get this to work as well as possible.  Then close the position loop with KFLOP+Kanalog.

But again if the errors are smaller than your requirements then this is probably all unnecessary.

#2 your speed is set a little too high.  Can you see that the output is saturating?  Reduce the speed (20%?) to avoid this.  Or possibly you can change VFD setting to allow higher speed for the same 10V input?

#3 It looks to me like you could change to infinite acceleration with very little change in performance.  For example if you look at your 2nd plot at ~ 11 seconds the Command trajectory stops in about 1 second.  But then the Position continues on, gets "stuck" for several seconds, etc.  If the stop occurred in 0.1 sec or instantly I wouldn't expect the overall result to be much different.

HTH
Regards
TK

Hi Greg,

Thanks for sharing.  Can't wait to see it actually cut something.

Good luck with the weather.

Regards

TK

 

Hi Tom,

You were correct, I was trying to use that setting for something it wasn't intended for.   For feedback the VFD's operate in "sensorless vector" mode.  The name is misleading.  It suggests no feedback, but what is meant is that there is no external sensor used for feedback.  Instead the VFD measures current and uses that in the feedback loop, this post describes it better http://www.practicalmachinist.com/vb/transformers-phase-converters-and-vfd/what-really-vector-sensorless-drive-276144/#post2170818

I went back to square one.  Reset the PID parameters in the VFD.  Ultimately ended up using the "auto tune" values the VFD came up with. 

Here is a plot of velocity using DAC commands.  Full speed is commanded for 5 seconds, then full reverse with no zero or delay, bit is toggled so you can see on the plot when the DAC command was sent.  This C code in a loop:
     DAC(CHANNELTOTEST, FULLSPEED_CW);
    SetStateBit(EVENTBIT, !ReadBit(EVENTBIT));
    Delay_sec(5);
  
    DAC(CHANNELTOTEST, FULLSPEED_CCW);
    SetStateBit(EVENTBIT, !ReadBit(EVENTBIT));
    Delay_sec(5);


 
And then I did a ramping test:
 
From these it seems that switching directions results in the delay and as you suspected is probably caused by backlash.  So I'm going to accept that for now.

This is where I settled:
    //xaxis   
    ch0->InputMode=ENCODER_MODE;
    ch0->OutputMode=DAC_SERVO_MODE;
    ch0->Vel = 45;
    ch0->Accel = 30;
    ch0->Jerk = 500;
   
    //test 2nd order speeds/accel/inf jerk
    //ch0->Vel=16.3;//max cutting speed
    //ch0->Vel=3.5;//min cutting speed
    //ch0->Vel=8;
    //ch0->Accel=3;
    //ch0->Jerk=500000000;
       
    ch0->P=140;
    ch0->I=0.0015;
    ch0->D=0;
   
    //yaxis
    ch1->InputMode=ENCODER_MODE;
    ch1->OutputMode=DAC_SERVO_MODE;
    ch1->Vel=100;
    ch1->Accel=150;
    ch1->Jerk=1000;
    //ch1->Jerk=10000000000;
    ch1->P=120;
    ch1->I=0.0015;
    ch1->D=0;

Unfortunately I'm running out of time as winter is supposed to hit here tomorrow and the saw will be under snow.  Today I was able to do a small test of some coordinated motion. I rigged up a pen to trace the movement, but the mount sucked and wasn't very ridged and it was pressing too hard on the paper.  So the drawn image is awful but I did log the error and it looks good.  For the most part error is less than 5 counts.  This is the error while drawing part of the circle (2" diameter):



Here's the image, it looks bad but I had to adjust the pen while it was moving and the mount wasn't ridged and it was humid out and the paper started to buckle...







Anyway this gives me hope. 

Also really like the screen editor. 



Thanks for your help getting it this far.
Greg.

 
On 11/1/2016 12:49 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Greg,

#1 I'm guessing that VFD Acceleration setting is Acceleration Feed Forward.  They take the derivative of the input, scale it by the setting, and add that to the output (Torque?).  I'm not sure it is very helpful.   I don't think your "problem" is with inertia.  Probably more to do with backlash, zero crossing distortion, and stiction.  Setting high Acceleration FF will give the system a big kick when the input changes which I thing is why you see some quicker response but probably isn't the right thing to do.  Something very similar could probably be obtained with higher gains. 

It isn't clear to me what the VFD uses for velocity feedback.  Do you know? Is there an encoder on it?

It might be worth while to characterize your VFD by simply commanding constant (or maybe ramping) velocity (DAC) commands.   Of course ideally the VFD should instantly go to and hold the commanded speed.   So this approach allows you to observe/test the VFD + Mechanism characteristics by themselves.  Crossing through zero speed would be of great interest.  Then adjust the VFD setting to get this to work as well as possible.  Then close the position loop with KFLOP+Kanalog.

But again if the errors are smaller than your requirements then this is probably all unnecessary.

#2 your speed is set a little too high.  Can you see that the output is saturating?  Reduce the speed (20%?) to avoid this.  Or possibly you can change VFD setting to allow higher speed for the same 10V input?

#3 It looks to me like you could change to infinite acceleration with very little change in performance.  For example if you look at your 2nd plot at ~ 11 seconds the Command trajectory stops in about 1 second.  But then the Position continues on, gets "stuck" for several seconds, etc.  If the stop occurred in 0.1 sec or instantly I wouldn't expect the overall result to be much different.

HTH
Regards
TK